This project reflects a longstanding NLM interest in clinical terminology and message standards. It uses and tunes the message and vocabulary standards that NLM has supported to facilitate interoperability, defined as communicating data from a source to a destination where it can be used in computing. (HIMSS Dictionary of Healthcare Information Technology Terms, Acronyms and Organizations, 2nd Edition, 2010, Appendix B, p190.) NLM has been at the nexus of standards needed to make clinical data flow from sources for clinical care and epidemiologic databases. We are directly engaged in work on HL7 electronic messaging standards related to Clinical Genomics Coded Reporting, and reporting results of newborn screening. The major code systems required by Meaningful Use regulations, LOINC, SNOMED, RxNorm, and UCUM, are all developed and/or supported by NLM. We continue to collaborate with other organizations to develop and promote the use of these standards. LOINC-related collaborations continued during FY2017 with: IEEE (importing the clinical variables that come out of IEEE monitoring, and electrophysiological instruments, e.g. Ventilators, anesthesia monitors, Infusion pumps, EEG, Nerve conduction). In FY2017, we achieved the fusion of RadLex and LOINC under the Radiologic Society of North America (RSNA) with support for NIBI and a major effort from the Regenstrief Institute; DICOM and Echocardiographers (measures from Echocardiograms); American Nurses Association (ANA) and others (create nursing assessment variables -- in progress); worked with CMS (to unify all of their clinical assessments as LOINC codes -- in progress); continued as part of a multi CMS contract; SNOMED/IHTSDO (mappings). We also completed the integration of IEEE 1O1O1A Observations Table with LOINC. NLM is developing standards-based tools and techniques that can be used in EHRs, PHRs, and research. We have made these tools open source and freely-available by publishing the source code on GitHub. They are Section 508-compliant (i.e., accessible to screen readers). Groups or institutions can customize many of the features for their particular needs. A) LHC-Forms: Form Rendering Widget LHC-Forms creates input forms for Web-based medical applications, EHRs, PHRs, and mobile health apps. LHC-Forms can render a powerful data entry form for laboratory panels, survey instruments, etc. from any of the 2,000+ panels defined in LOINC. Implementers can also use it to develop forms based on their own arbitrary variables. The Web browser turns form descriptions into live forms via a rendering program (about 300K bytes compressed) that it can load once and use repeatedly. The forms can be described in a spreadsheet or in JSON the ultimate target format and can be authored with the NLM form builder. LHC-Forms supports many form attributes, including: data type, cardinality, default value, units of measure (if numeric), answer lists and multiple choice/multiple answer variables, relationship (in a nested hierarchy) to other questions, scoring of survey instruments, default value settings, validation checks to ensure quality data collection, skip logic (so questions can dynamically appear/disappear based on value recorded in multiple other questions) and help messages. LHC-Forms uses the NLM-developed autocompleter package (autocomplete-lhc) described below. Data types, data structures and conventions are parallel to the widely-adopted HL7 V2 electronic message standard, and a completed form can be converted to an HL7 v2 message. It also has the ability to accept, store, and display FHIR Questionnaire resources and output FHIR DiagnosticReport and QuestionnaireResponse messages. The Office of Management and Budget (OMB) has adopted LHC-Forms for a pilot testing its use in its large data systems. Try it: https://lhc-forms.lhc.nlm.nih.gov. Programmers interested in using LHC-Forms in their own EMR, PHR, or other application can download the LHC-Forms software and view the documentation at http://lhncbc.github.io/lforms/. Developers can add their own custom solutions for storing data, authentication, and user control. As an example of a simple solution for these pieces, we have a demo application using a HAPI FHIR server for storage of FHIR output from LHC-Forms that uses Firebase for authentication and user control. Our related Form Builder tool enables users to build and customize forms using an informative dashboard with real-time updates that display user selections. It can also output the built form definitions as FHIR Questionnaires, and store and retrieve Questionnaires from the FHIR server. B) Clinical Table Search Service The Clinical Table Search Service provides look up functions to tables such as master files and coding systems, in order to provide answer lists for fields in many forms. The service connects tables to fields in the form by URLs whose parameters control what table to search, which fields to return to the choice menu grid, and which fields of the selected item to store as hidden content in the input fields. We have added to the number of coding systems that users can browse and expanded functionality. The coding systems include most of the major genetic databases from NCBI as well as from Cosmic Cancer Mutation and EBI. Our implementation provides preconfigured API access to many clinical tables: LOINC, RxTerms, ICD-10-CM, most NCBI genomics tables, COSMIC, National Provider Identifiers, and others. Try it: https://clin-table-search.lhc.nlm.nih.gov. C) Validator and converter for UCUM units of measure. Standard units of measure are essential to the use of numeric variables in clinical care and research. Currently, they are not standardized and use varying strings. In a large sample of HL7 messages we found 60 different ways to express the units for a red blood cell count. The Universal Code for Reporting Units of Measure (UCUM) was developed to solve this problem. It accommodates all metric units and every kind of conventional unit, plus those that are not so conventional (http://unitsofmeasure.org/). It also includes a formal definition of the syntax and tables with coefficients and other attributes for converting between different units of measure. Standard units are needed to exchange and aggregate numeric values (e.g. laboratory test results and vital signs), or to utilize them for clinical decision support. UCUM has been adopted by most clinical standards organizations, including ANSI approved standards development orgs (SDOs): HL7, IEEE (instrument measurements), DICOM (radiology measurement), and ISO-11240 for development of medicinal products. It is required by meaningful use for HL7 for Public Health laboratory reporting, and for most measurements in HL7s CDA reporting. We developed an open source JavaScript UCUM validator and conversion library that will verify that units strings claiming to be UCUM units are valid UCUM units, can batch validate the units in a table submitted as a CSV file, and can also convert values reported as one specific UCUM unit to another commensurate UCUM unit (e.g. ounces to kilograms), which could help aggregate or analyze data from multiple sources. Try it: http://lhncbc.github.io/ucum-lhc/demo.html. Finally, we have revised and completed the balloting of a HL7 V2 genetic reporting implementation guide as part of the Laboratory Results Interface (LRI) of HL7. This is the test of all the coding systems listed above.